Amazon EKS
https://gyazo.com/fa0a8f5bb626e7cdb7ed9404d0a840cb
AWSが提供するマネージドKubernetesサービス
何を解決するか
Kubernetesを自前運用すると、この辺の管理が大変
etcd・API server・scheduler・controller managerの可用性確保
バージョンアップ
セキュリティパッチ当て
ユーザはワーカーノードとアプリだけに集中できる
構成要素
API server, etcd, scheduler などを AWS が3 AZで運用
バージョン管理・パッチ適用も AWS 側
ユーザーからは見えない（kubectl越しに触る）
データプレーン（ユーザー管理 or マネージド）
セルフマネージドノード: 自分でEC2を立ててクラスタにjoin
マネージドノードグループ: EC2のライフサイクル管理をEKSに任せる（推奨）
Fargate: ノードレスでPod単位の実行。EC2管理不要だがコスト高め
ハマりどころ
Pod数上限: VPC CNIだとノードのENI数 × IP数で上限が決まる。小さいインスタンスだとPodが乗らない
バージョンアップ: K8sのサポート期間が短い（約14ヶ月）ので継続的にアップグレード必要
IAMとRBACの二重管理: aws-auth ConfigMapでマッピングが必要（最近はAccess Entriesで改善）
コスト: Fargateは便利だが本気で使うとEC2より高くつくことが多い
Karpenter とその他必要なアドオン（ネットワーク、ストレージ、Ingressなど）を AWS が事前にセットアップしてくれて、Nodeを自分で管理しなくてよくするというもの。 table:_
観点 EKS 従来 EKS Auto Mode
コントロール コントロールプレーンのみAWS コントロール + Node 両方AWS
Node 自分でNodeGroup作る or Karpenter自前運用 AWS管理のNodeが自動で湧く
OSアップデート 自分で計画 自動
柔軟性 高い（細かく制御できる） 制約あり（一部設定が効かない）
柔軟性を捨てて運用負荷を減らす
Auto ModeのKarpenterはユーザが裏側のNode設定を勝手にいじれないようになっている
コンテナ化の失敗